Open Bug 1217841 Opened 10 years ago Updated 3 years ago

Text-selection indicators (carets) should be oriented sideways when the text has vertical writing-mode

Categories

(Core :: DOM: Selection, defect)

ARM
Gonk (Firefox OS)
defect

Tracking

()

People

(Reporter: jfkthame, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(4 files)

Go to http://www.mongolfont.com/test/firefox/div.html on FirefoxOS, and select some text in one of the vertical writing-mode text areas. As expected, the selection start/end carets (blue "droplets") appear, pointing to the beginning and end of the selected text. But they "hang" downwards, just like in horizontal text, which means that the start-of-selection indicator obscures the first few characters of the selected text. (See screenshot.) Instead, they should be oriented in the block-progression direction of the text: in Chinese/Japanese text with writing-mode:vertical-rl, they should appear to the left of the text, with the tip pointing rightwards; and in Mongolian, with writing-mode:vertical-lr, they should appear to the right, pointing leftwards.
Hmm, on looking around a bit, I wonder if this is really a Gecko issue... it looks like the code in layout/base/SelectionCarets.cpp may be responsible for figuring out the placement and styling of these. So probably that code needs to become aware of writing-mode. Moving this to Core::Layout, as that seems closer to where it belongs.
Component: Gaia::System::System UI → Layout
Product: Firefox OS → Core
Blocks: writing-mode
I also file a bug for UX team to update the caret spec in bug 1217757.
See Also: → 1217757
Hi Jonathan, It's good to see you have patches for the carets on B2G. However, I'm afraid that SelectionCaret you're patching are no longer deployed on B2G master. TouchCaret (for one caret when selection is collapsed in editable content) and SelectionCarets are being unified by AccessibleCaret. AFAIK, Fennec also have a plan to deprecate TouchCaret and SelectionCarets, and migrate to AccessibleCaret in Bug 1215959. If you're still interested in patching AccessibleCaret, please do so. I would be happy to help. Otherwise I can port your patches to AccessibleCaret, and learn something about writing mode. :) https://wiki.mozilla.org/Copy_n_Paste
Thanks for the info. OK, I won't bother trying to get these patches reviewed & landed, if this code is dead already! I'll attach the current state of my SelectionCaret and TouchCaret patches here, just for reference. If you can take over this, and port the necessary changes to AccessibleCaret, that would be great; I don't really have time to work on this at the moment. A couple of notes about the WIP patches here: For vertical writing modes, I created "vlr" and "vrl" versions of all the image resources used, but these are not strictly correct, they were just placeholders for testing. I notice that the images have a slight shadow, and my vlr/vrl versions are simply rotated copies of the originals, which means the shadows are not correct, because they now point sideways instead of downwards; the images really should be re-rendered with proper shadow direction. Also, I was intending to suggest (as a followup) that we should restructure the caret rendering to get rid of all the text_cursor*.png images with their various resolutions, and instead just use a glyph from a custom font (loaded via @font-face, probably using a data: URL as the font should be very small, containing only a few simple glyphs) to render the carets. This would automatically deal with the issue of different device resolutions, and allow us to get rid of a whole mass of @media (min-resolution...) blocks and CSS rules. And we wouldn't need separate assets for vertical writing modes, either; we'd just apply the appropriate writing-mode to the caret element, and it would render with the correct orientation. This would also make it trivial to do things like vary the colors of the carets and adjust their shadow (implemented via CSS color & text-shadow), without needing to regenerate a whole collection of PNG images for any experimental change in styling.
Thanks for the WIP patches and note. I'll see what I can do.
Assignee: nobody → tlin
Status: NEW → ASSIGNED
Depends on: 1217751
No longer depends on: 1217751
Component: Layout → Selection
Depends on: 1249548
Assignee: tlin → nobody
Status: ASSIGNED → NEW
See Also: → 1559739
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: